Thanks for your PR:

I think we could create an alias class for the old Cms class names. This way we will be able to keep compatibility with v3.

So something like:

<?php

namespace Kirby\Kql\Interceptors\Cms;

use Kirby\Kql\Interceptors\Content\Content as NewContent;

class Content extends NewContent
{
}

Thanks for the hint! To add backwards compatibility to my Kirby 3 projects, I currently rely on a similar class alias for my libraries, which basically only require one change for Kirby 4 compatibility:

// Add backwards compatibility for Kirby 3
if (!class_exists('Kirby\Content\Field')) {
    class_alias('Kirby\Cms\Field', 'Kirby\Content\Field');
}

I'm not sure my PHP knowledge will be sufficient to replicate that using your approach for my PR, but I will give it a shot.

Thanks for the ideas @lukasbestle, which I have implemented accordingly. But I'm running into a problem with Psalm that I can't seem to solve. Perhaps the solution is obvious to you.

Hm, good point. Maybe a class alias could actually work as well:

use Kirby\Kql\Interceptors\Content\Content;
use Kirby\Kql\Interceptors\Content\Field;

class_alias(Content::class, 'Kirby\Kql\Interceptors\Cms\Content');
class_alias(Field::class, 'Kirby\Kql\Interceptors\Cms\Field');

Could you please revert composer.json and composer.lock to the currently released state? I think it would be good to keep the version requirements unchanged unless we need to.

For sure! Done.

Great! Thanks for the mentoring on this PR, @lukasbestle. Pretty insightful. 🙂

Regarding real-live testing, I'm using my fork (on which this PR is based on) for both K3 in production and a K4 test site. I can verify it works.

This is my setup (relevant lines extracted):

{
  "require": {
    "getkirby/cms": "^3.9",
    "getkirby/kql": "dev-v4-compat"
  },
  "repositories": [
    {
      "url": "https://github.com/johannschopplich/kql-fork.git",
      "type": "git"
    }
  ]
}